In recent years graphical user interface (GUI) test automation has advanced from record and play to data driven GUI test automation. Through these advances test automation systems have become more user-friendly and have improved in efficiency. The improved systems allow scripts to be reused and allow individuals without programming experience to create and execute scripts. Many of the current systems enable superior software to be developed more quickly than was previously possible. One area of GUI test automation that continues to see advances is GUI map management.
GUI maps are important for any test automation system. GUI maps allow objects to be mapped from names that test automation system testers recognize to data formats that automation tools can understand. GUI maps contain logical names and physical descriptions of objects in corresponding applications. FIG. 1A shows a typical authentication window associated with an application program. A conventional type GUI map of the authentication window shown in FIG. 1A is shown in FIG. 1B. Correspondences between the logical names and the physical descriptions of the objects associated with the authentication window are shown in FIG. 1C.
It should be appreciated that when tests are run, the automation tool reads statements, which contain logical names of objects located in the GUI and searches the GUI map for the logical names. The logical names point the tool to the physical description of the object in the GUI map. Using the physical descriptions to locate the position of the object in the GUI, the tool can easily find the matched objects. For example, to perform the login, the following code can be used:                set_window(“authentication”5)        edit_set(“username:”, “tester1”)        edit_set(“password:”, “12345”)        button_press(“OK”)        
In a conventional automated system such as that discussed with reference to FIGS. 1A-1C, all objects associated with a window are listed under that window's description (see FIG. 1A, the corresponding GUI map of FIG. 1B, and the corresponding physical descriptions of FIG. 1C). The different windows that appear in a particular application are listed in the GUI map for that application as shown in FIG. 1D.
Conventional test automation systems have serious shortcomings. Most conventional systems allow considerable latitude in mapping of objects. It should be appreciated that each map corresponding to particular applications need modification once a change in the application is made. Additionally, to accommodate different applications, the automated test system has to use different maps. Managing the necessary changes and maps involved is a considerable challenge.
Shortcomings of the conventional systems can be exposed when changes to the application are made in development. Examples of types of changes that could be made to the window shown in FIG. 1A during development that could affect it's GUI map are for instance, a change in the first edit box to “UserID” from “Username:” or in the “OK” button to “login”. Such changes in the application involve corresponding modifications to the associated GUI map. It should be appreciated that such changes can be expected to occur more than once before a product releases.
The window map shown in FIG. 1E is a table of all objects with their appropriate accessing method. This approach attempts to help the scripter to avoid having to map objects to specific window elements. However, this approach involves all objects being scanned. Additionally, it only helps during mapping, and still needs to be modified if there is any change in an application after the table is established.
Another problem occurs when old scripts are reused with different applications as is customary with most test automation systems. Since each application has its own arrangement of windows and objects, their respective GUI maps are different. With conventional approaches a GUI map has to be maintained for each application. Consequently, if 100 applications are served 100 GUI maps must be maintained. As such, existing GUI maps cannot be immediately used with new applications; a revised GUI map must be created.
The drawings referred to in this description should not be understood as being drawn to scale except if specifically noted.